Contact centers, such as Automatic Call Distribution or ACD systems, are employed by many enterprises to service customer contacts. A typical contact center includes a switch and/or server to receive and route incoming packet-switched and/or circuit-switched contacts and one or more resources, such as human agents and automated resources (e.g., Interactive Voice Response (IVR) units), to service the incoming contacts. Contact centers distribute contacts, whether inbound or outbound, for servicing to any suitable resource according to predefined criteria. In many existing systems, the criteria for servicing the contact from the moment that the contact center becomes aware of the contact until the contact is connected to an agent are customer-specifiable (i.e., programmable by the operator of the contact center), via a capability called vectoring. Normally in present-day ACDs when the ACD system's controller detects that an agent has become available to handle a contact, the controller identifies all predefined contact-handling skills of the agent (usually in some order of priority) and delivers to the agent the highest-priority oldest contact that matches the agent's highest-priority skill. Generally, the only condition that results in a contact not being delivered to an available agent is that there are no contacts waiting to be handled.
The primary objective of contact center management, including call-distribution algorithms, is to ultimately maximize contact center performance and profitability. An ongoing challenge in contact center administration is monitoring of agent behaviors to optimize the use of contact center resources and maximize agent performance and profitably. Current products for monitoring and reporting on contact center performance, such as Call Management System or CMS™ by Avaya, Inc., are configured as data warehouses that extract data from multiple sources, transform the data into a normalized form, and load the data into the data warehouse database, typically on a batch schedule. Additional calculations and reporting are performed after the batch load.
A common type of data warehouse is based on dimensional modeling. Dimensional modeling is a data model that divides the world into measurements and context. Measurements are usually numeric and taken repeatedly. Numeric measurements are facts. Facts are surrounded by textual context in existence when the fact is recorded. Context is often subdivided into dimensions. Fact tables are used in dimensional modeling to logically model measurements with multiple foreign keys referring to the contextual entities. The contextual entities each have an associated primary key. A “key” is a data element (e.g., attribute or column) that identifies an instance of an entity or record in a collection of data, such as a table. A “primary key” is a column or combination of columns whose values uniquely identify a row in a table or is the attribute or group of attributes selected from the candidate keys as the most suitable to uniquely identify each instance of an entity. A “foreign key” refers to a column or combination of columns whose values are required to match a primary key in another table or is a primary key of a parent entity that contributes to a child entity across a relationship. Types of primary keys include a natural key, or a key having a meaning to users, and a surrogate key, or a key that is artificially or synthetically established, meaningless to users, and used as a substitute for a natural key.
If the same entity (e.g., agent) is represented on multiple data sources (e.g., inbound call system and outbound call system) by different natural keys, a traditional data warehouse generates and assigns a surrogate key to identify the entity. The surrogate key is an internal identifier managed by the data warehouse. For example, in a contact center an agent may handle inbound calls from one system and outbound calls from another system, with different identities on each system. Data warehouses commonly process each data source independently, performing data correlation across sources at a later time.
Some data models specify a behavior known as a type 2 slowly changing dimension. A type 2 dimension tracks the history of changes to an entity over time. When an attribute of an entity is changed, such as when a contact center agent changes their skill set or group membership, a new surrogate key for that entity is generated, and a new row inserted into the database. Fact data associated with the entity can now be tracked separately for activities that occurred before versus after the change by referencing the appropriate surrogate key.
An ongoing issue confronting vendors of contact center software products, particularly products including dimensional modeling software, is integration of the enterprise database applications (or application software), typically purchased from other vendors, with the contact center software. The vendor of the contact center software desires ease of integration with the existing enterprise database application software but must be careful that the integration of the software does not lead to semantical inconsistencies and other conflicts that can result in reporting inaccuracies or, even worse, software malfunctions.
A number of approaches have been employed to address this issue.
In one approach, the database provides a limited ability to control the types of extensions a particular database user can make. For example, a database table owner disallows column deletion to protect existing data. The table owner may also wish to allow columns to be added to the table and can configure the database to allow a table user to add a fixed set of columns. However, if the existing columns have constraints on their values beyond the conventional relational model, there is no way to ensure that data in the new columns adheres to those constraints. For example in dimensional modeling, dimension tables with type-2 keys have particular rules about when a new key must be generated. Basically, if the value of any of the non-type-2 key columns changes, an entire new row with a new type-2 key and a complete copy of all up-to-date data are inserted to the table. This arrangement can preserve the historical information associated with the dimensional table. However, allowing an arbitrary third party to create such columns requires the third party to participate in the type-2 key semantics. Unfortunately, databases do not provide a way to guarantee the type-2 semantics. For example, the customer can undo a type-2 key change done by the contact center database software or vice versa. Moreover, this approach has also suffered from race conditions that could cause loss of updates.
In another approach, database triggers on the table are used to watch for third party changes, which, when identified, are followed by an application applying appropriate type-2 semantics. Unfortunately, such an approach frequently leads to race conditions between the application and the third party that prevent proper logical semantics from being maintained. Simply put, there is no way to control the third party's timing associated with changes to the extended column set. Often times, the application is unwilling to allow changes to a table for some reason while an Extract, Transform, and Load or ETL module is computing summaries from the table, for example.
Another approach uses transactions or “database locking” in which change requests (transactions) are delayed for a determined period of time. Database locking may help but can be difficult to use for a complete solution. For instance, if the transaction hold time is long-lived, the third party's application or the contact center application may be bogged down.